Inhalt: Hier werden alle compilerspezifischen Dinge beschrieben.
        Falls noch nicht geschehen, bitte zuerst die Datei INSTALL.TXT lesen.


Nicht untersttzte Compiler
===========================

o ana-systems m2 (ANAM2):
  Ein Shareware-Compiler, der sich an PIM2 orientiert; der
  Hauptnachteil ist aber, da er keine arithmetischen 16-Bit-Typen
  kennt. (Und einige Compilerfehler gibt's auch.)

o Modular Systems (MSM2):
  Orientiert sich auch irgendwo zwischen PIM2 und PIM3, hat aber viel
  zuviele Eigenheiten.

o FTL-Modula (FTLM2):
  Hat einige Compilerfehler, die einem das Leben schwer, wenn nicht
  gar unmglich machen, zumindest in der Version 1.18 (z.B. fehlerhafte
  Mengenoperationen, Probleme beim Reexport, Fehler beim Lesen und Setzen
  von Prozessorregistern, Fehler beim Casten).

Diese Systeme werden auch in Zukunft nicht untersttzt, da ihre
Bercksichtigung entweder nicht mglich ist oder zuviel Aufwand verursacht.


Untersttzte Compiler
=====================

Es folgt eine Auflistung der untersttzten Compiler mit einer kurzen
Erluterung der zustzlich vorhandenen Dateien, sowie weitere
compilerspezifische Hinweise, die fr M2LIB relevant sind.

Alle compilerspezifischen Dateien befinden sich im Unterverzeichnis
COMPILER\, das weitere Unterverzeichnisse mit den Namen der Compiler
enthlt, in denen wiederum Verzeichnisse mit den eigentlichen Dateien
enthalten sind.


LPR (PD-Compiler der TU-Mnchen), Version 1.4 (LPRM2):
------------------------------------------------------
o Verzeichnisse:
  LPRM2\
    BATCH\
    LPR_DOC\
    LPR_SRC\
    OBMINFO\
    PATCHES\

o Um das Verzeichnis mit den M2LIB-Objektdateien (normalerweise das
  Verzeichnis M2LIB) dem System als Suchpfad bekannt zu machen, mu der
  vollstndige Pfad inkl. abschlieendem Backslash (ohne diesen werden
  keine Dateien gefunden) in der ASCII-Datei M2PATHS.TXT eingetragen werden.
  Der Pfad mu vor der letzten Zeile stehen; am besten in der ersten Zeile,
  damit es nicht zu Konflikten mit evtl. bereits vorhandenen gleichnamigen
  Dateien in anderen Verzeichnissen kommt. Befinden sich die M2LIB-Dateien
  aufgeteilt in mehreren Verzeichnissen, sind entsprechend alle diese Pfade
  (direkt hintereinander) in M2PATHS.TXT einzutragen.

  Sollen die Module (neu) bersetzt werden, mu ebenfalls ein Suchpfad fr
  die Quelltexte in M2PATHS.TXT eingetragen werden. Es ist empfehlenswert,
  fr das bersetzen ein gesondertes (temporres) Verzeichnis zu whlen und
  nach dem bersetzen die Objektdateien in das dafr vorgesehene, permanente
  Verzeichnis zu kopieren. Gnstig ist z.B. ein Verzeichnis auf einer
  RAM-Disk, damit das Einlesen der Dateien schnell vonstatten geht und die
  Festplatte nicht im Dauerstre ist.

o BATCH\:
  Enthlt die Batchdateien MKPOSIX.CM, MKISO.CM, MKMISC.CM fr die
  Bibliotheksmodule und MKXTEST.CM, MKITEST.CM, MKMTEST.CM fr die
  zugehrigen Testmodule, mit deren Hilfe der Compiler alle prprozessierten
  Module in einem Rutsch bersetzt.
  Die Bibliotheksmodule mssen in folgender Reihenfolge bersetzt werden:

    MKPOSIX.CM
    MKISO.CM
    MKMISC.CM

  Die Testmodule knnen natrlich erst bersetzt werden, wenn die zu
  testenden Bibliotheksmodule bersetzt sind.

  Eine Batchdatei wird dem Compiler genauso wie eine normale Moduldatei
  zum bersetzen angeboten, nur da dann alle Module, deren Name in der
  Batchdatei enthalten ist, bersetzt werden. Leider lt sich der Vorgang
  nicht abbrechen. Bei einem bersetzungsfehler mu eine Alarmbox besttigt
  werden, damit weitergemacht wird; auch hierbei gibt es keine Mglichkeit
  den Vorgang abzubrechen.
  Die Batchdateien mssen sich im selben Verzeichnis wie die zu
  bersetzenden Module befinden.

o LPR_DOC\:
  Enthlt eine Textdatei, die einige Interna und Eigenheiten des LPR-Systems
  beschreibt.

o PATCHES\:
  Fr die Funktionen "DosSystem.[at]exit()" ist es ntig, das
  LPR-Laufzeitsystem um eine Modulterminierung zu erweitern. Bei der
  Gelegenheit wird das Startup-Modul GEMX auch gleich fr ACCs vorbereitet
  und andere Dinge. Nheres ist dem README und den Quelltexten zu entnehmen.
  Wer lediglich die Modulterminierung ohne die anderen Erweiterungen haben
  will, braucht die Patchprogramme FIXLINK bzw. FIXPRG nicht. Umgekehrt gilt
  das nicht: Wer FIXLINK oder FIXPRG benutzt, mu unbedingt auch das neue
  GEMX verwenden!!

  Wegen des neuen GEMX ist auch ein gendertes 'Heap' ntig, bei dem auch
  gleich ein Fehler des Originals beseitigt wurde: Das Original-Modul konnte
  unter Umstnden zum Absturz fhren, da die Listenverkettung der freien
  Speicherblcke zerstrt wurde. Um auch beim Load-Time-Linking das
  korrigierte Heap zu haben, mu M2Loader einfach mit dem neuen GEMX und
  Heap gelinkt werden. Danach aber nicht vergessen, Stack- und Heapgre
  mit FIXPRG zu ndern, Vorschlag: Stacksize = 32kB, Heapsize = 600kB.

  WICHTIG: Das neue GEMX bentigt das neue Heap und umgekehrt!

  Das neue GEMX.OBM und das neue HEAP.OBM kommen in das LPR-Verzeichnis
  STANDALO.NE und ersetzen die Originalmodule. LPRTERMI.SBM und LPRTERMI.OBM
  kommen am besten ins LPR-Verzeichnis SYSTEM.

  Die Modulterminierung funktioniert jedoch ausschlielich bei gelinkten
  Programmen. Um in der Shell (beim Load-Time-Linking) eine Modulterminierung
  zu haben, mu eine spezielle Variante des Moduls 'DosSystem' erzeugt
  werden. Hierzu wird beim Prprozessieren das Makro LPR_LTL_MTERM am Anfang
  der Datei definiert.
  WICHTIG: Dieses 'DosSystem' darf nur beim Load-Time-Linking verwendet
  werden, nicht bei gelinkten Programmen! Bei gelinkten Programmen mu die
  normale 'DosSystem'-Version benutzt werden (Makro LPR_LTL_MTERM nicht
  definiert)!!

  Das 'DosSystem' fr's Load-Time-Linking kommt zusammen mit den anderen
  M2LIB-Objektdateien in das dafr vorgesehene Verzeichnis, whrend die
  Version fr gelinkte Programme in das LPR-Verzeichnis STANDALO.NE kommt.
  Der Linker benutzt dann automatisch dieses Modul, whrend die Shell das
  andere 'DosSystem' verwendet. Das Verzeichnis STANDALO.NE darf nicht als
  Suchpfad definiert sein, also nicht in M2PATHS.TXT erwhnt werden, da
  sonst auch die Shell (bzw. der Lader) dort nach Dateien sucht. (Der Linker
  bercksichtigt STANDALO.NE automatisch.)

  Das Programm RTSPATCH.TOS, patcht das LPR-Laufzeitsystem, was fr eine
  korrekte Funktion der (LONG)REAL-Arithmetik und damit auch der ISO-Module,
  die sich mit REAL beschftigen, notwendig ist. Weitere Informationen hierzu
  stehen im Quelltext und der Textdatei.

(Die Textdatei und das Patchprogramm waren schon in meiner alten HK_LIB_1.2
enthalten, deshalb ist deren Erwhnung an einigen Stellen in den Texten
einfach zu ignorieren.)

o LPR_SRC\:
  Enthlt eine Reihe von LPR-Originalmodulen, die nach Modula rckkompiliert
  wurden. Die Dateien sind teilweise schon mehrere Jahre alt.

o OBMINFO\:
  Enthlt ein Programm samt C-Quelltext, mit dem sich einige Informationen
  aus bersetzten Modulen gewinnen lassen, was fr die Rekompilierung
  ganz ntzlich ist. Es gibt keine Dokumentation, allerdings werden im
  Programm die in LPR_DOC\LPR_M2.TXT enthaltenen Informationen ber
  OBM-Dateien verwendet.
  Der Aufruf lautet: obminfo <obmfile> [<outfile>]

    <obmfile> ist der Name des zu analysierenden Moduls (*.OBM)
    <outfile> ist der Name einer Datei, in die die Analyse geschrieben
              wird. Ist <outfile> nicht angegeben, wird die
              Standardausgabe (Bildschirm) verwendet.

o Beim LPR-Compiler mssen per Hand alle Tests in der Shell ein- oder
  ausgeschaltet werden, da es keine im Quelltext aktivierbaren
  Compileroptionen gibt.

o Leider werden die entstehenden Programme, im Gegensatz zu den anderen
  Compilern, ziemlich gro, da der Linker nicht optimiert, aber dieses
  Problem ist ja nicht M2LIB-spezifisch. Importiert man aus einem der
  Reexportmodule, wie POSIX1, wird es aber besonders deutlich.

o Der Lader (M2LOADER.PRG, M2Loader) ist nicht ``32-Bit-clean''. Unter
  anderem deswegen luft das System nicht auf Rechnern mit 680x0-CPU.
  Abhilfe schafft mglicherweise 24BIT.PRG oder ein anderes Programm, das
  Adressen auf 24 Bit begrenzt. Weiterhin wird nicht bercksichtigt, da
  eine 680x0-CPU bei einer Ausnahme mehr Werte auf dem Stack ablegt als
  die 68000-CPU.

o Das Load-Time-Linking ist am Betriebssystem vorbei programmiert, d.h.
  Module, die in der Shell gestartet werden, werden nicht ber 'Pexec'
  geladen, sondern lediglich als normale Datei eingelesen und dann durch
  Shell-interne Methoden gestartet. Das hat zur Folge, da diese Module
  fr das Betriebssystem keine eigenstndigen Prozesse sind -- die Shell
  selbst ist der einzige Proze. Werden nun innerhalb eines solchen Moduls
  prozespezifische Parameter verndert, betreffen diese nderungen nicht
  nur die gesamte Shell, sondern auch alle anderen, spter gestarteten
  Module! Das ist schon unter reinem TOS ein Problem, denn z.B. Speicher
  und Dateikennungen werden prozeweise verwaltet; unter einer Multitasking-
  Erweiterung wie MiNT jedoch hat dies weitaus grere Auswirkungen. Ein
  krasses Beispiel sind z.B. mit 'Psignal' oder 'Psigaction' installierte
  Signalhandler. Wird ein solcher Handler installiert, z.B. fr das Signal
  SIGCHLD, das normalerweise ignoriert wird, so existiert er fr das
  Betriebssystem auch nach Ende des Moduls weiter. Wird jetzt ein anderes
  Modul geladen, das keinen Handler fr SIGCHLD installiert, und dem Modul
  wird dieses Signal gesendet, weil ein von ihm gestarteter Unterproze
  beendet worden ist, so fhrt das zum Absturz, weil an der angegebenen
  Adresse gar kein Handler mehr existiert! Auf diese Weise gibt es auch
  mit anderen Prozeparametern Probleme, was wahrscheinlich der Hauptgrund
  dafr ist, da das Load-Time-Linking unter MiNT so oft Probleme macht.
  Ein weiteres Beispiel ist das Duplizieren von Prozessen mit 'Pfork': da
  der Adrebereich der gesamten Shell kopiert werden mu, reicht hier
  oftmals nicht der Speicher, obwohl das ausfhrende Modul selbst sehr
  wenig Speicher braucht.

  Programme, die solche prozespezifischen Parameter verndern, sollten
  in der Regel also weder direkt noch indirekt von den Funktionen des
  Loaders Gebrauch machen. Das bedeutet zum einen, da sie nicht aus der
  Shell heraus gestartet werden sollten, sondern als eigenstndige, gelinkte
  Programme; zum anderen, da sie selbst auch keine Module zur Laufzeit
  nachladen sollten.

o Folgende (Original)Module des LPR-Systems werden in den Bibliotheksmodulen
  verwendet:
  - 'Heap' im Modul 'pSTORAGE', wenn Makro __USE_MEM__ nicht definiert ist.
  - 'GEMX' (siehe oben) im Modul 'DosSystem'.
  - 'LPRTERMINATION' (siehe oben) im Modul 'DosSystem'.
  - 'M2Loader' im Modul 'DosSystem', falls die Variante fr's
    Load-Time-Linking verwendet wird.
  - 'InOut' im Modul 'StdInOut'.

  Und zustzlich in den Testmodulen:
  - 'InOut', 'LongInOut' und 'RealInOut' im Modul 'pOUT'.
  - 'InOut' in 'T[L]MathUtil', 'TConvUtil' und den ISO-Testmodulen.
  Alle *InOut-Module stammen nicht direkt aus dem LPR-System, sondern
  von der ST-Computer PD-Diskette #285.


SPC, Version 2.0 (SPCM2):
-------------------------
o Verzeichnisse:
  SPCM2\
    BATCH\

o Um das Verzeichnis mit den M2LIB-Objektdateien (normalerweise das
  Verzeichnis M2LIB) dem System als Suchpfad bekannt zu machen, mu der
  Pfad in der ASCII-Datei PROFILE.CNF eingetragen werden (als ObjPath?);
  am besten als erster Pfad, damit es nicht zu Konflikten
  mit evtl. bereits vorhandenen gleichnamigen Dateien in anderen
  Verzeichnissen kommt (z.B. Systemdatei RealConversions!).
  Genaueres ber PROFILE.CNF ist dem Handbuch zu entnehmen.

  Fr das bersetzen der Module mu ebenfalls ein Suchpfad in PROFILE.CNF
  eingetragen werden (als Path?). Es ist empfehlenswert, fr das bersetzen
  ein gesondertes (temporres) Verzeichnis zu whlen und nach dem bersetzen
  die Objektdateien in das dafr vorgesehene, permanente Verzeichnis zu
  kopieren. Geeignet ist z.B. ein Verzeichnis auf einer RAM-Disk, damit das
  Einlesen der Dateien schnell vonstatten geht und die Festplatte nicht im
  Dauerstre ist.

o In der STDLIB gibt es ein Modul namens 'RealConversions', das auf acht
  Zeichen gekrzt den Dateinamen REALCONV.* hat. In der ISO-Lib gibt es ein
  Modul 'RealConv', das als Datei ebenfalls REALCONV.* heit. Wie oben
  bereits gesagt, mu deswegen der Suchpfad mit den M2LIB-Dateien vor dem
  Suchpfad mit den SPC-Dateien stehen, da sonst das falsche Modul gefunden
  wird. Auerdem drfen keine (SPC-)Module verwendet werden, die das
  SPC-RealConversions importieren.

o BATCH\:
  Enthlt die Batchdateien MKPOSIX.CMD, MKISO.CMD, MKMISC.CMD fr die
  Bibliotheksmodule und MKXTEST.CMD, MKITEST.CMD, MKMTEST.CMD fr die
  zugehrigen Testmodule, mit deren Hilfe der Compiler alle prprozessierten
  Module in einem Rutsch bersetzt.
  Die Bibliotheksmodule mssen in folgender Reihenfolge bersetzt werden:

    MKPOSIX.CMD
    MKISO.CMD
    MKMISC.CMD

  Die Testmodule knnen natrlich erst bersetzt werden, wenn die zu
  testenden Bibliotheksmodule bersetzt sind.

o Bei der Behandlung von (LONG)REAL-Konstanten sind ein paar Dinge zu
  beachten:
  - LONGREAL-Konstanten werden wie bei LPR mit einem D gekennzeichnet:
      1.2345678D    (* Fixpunkt, REAL: 1.2345678 *)
      1.2345678D15  (* wiss. Format, REAL: 1.2345678E15 *)

  - Wenn LONGREAL-Konstanten grer oder gleich 1.0D64 auftauchen,
    bricht der Compiler das bersetzen mit einem berlauffehler ab.

  - Wenn vor dem Dezimalpunkt mehr als sieben Ziffern stehen, gibt es
    den Syntaxfehler "number too large", obwohl die Zahl selber gar
    nicht zu gro ist! Dies gilt sowohl fr REAL- als auch fr LONGREAL-
    Konstanten. Beispiel:

      1234567.890  ist OK, aber
      12345678.90  gibt "number too large"

  - Vom Compiler werden maximal sieben Stellen hinter dem Dezimalpunkt
    bercksichtigt. Zusammen mit den maximal sieben Stellen vor dem
    Dezimalpunkt kann man eine LONGREAL-Konstante mit maximal 14-stelliger
    Genauigkeit angeben; d.h. es ist mit SPC nicht mglich, LONGREAL-
    Konstanten in der vollen Genauigkeit (16 Stellen) anzugeben.
    Aus diesem Grund werden in den entsprechenden ISO-Modulen initialisierte
    LONGREAL-Variablen statt -Konstanten verwendet.

o Leider werden die entstehenden Programme, im Gegensatz zu den anderen
  Compilern, ziemlich gro, da der Linker nicht optimiert, aber dieses
  Problem ist ja nicht M2LIB-spezifisch. Importiert man aus einem der
  Reexportmodule, wie POSIX1, wird es aber besonders deutlich.

o Das SPC-Laufzeitmodul 'System' installiert sich in verschiedenen
  Betriebssystemvektoren (ohne XBRA natrlich...) wie z.B. die fr
  Addrefehler und Busfehler. Dies gilt dann natrlich auch fr gelinkte
  Programme, ohne da man darauf Einflu hat, obwohl sowas eigentlich der
  Entwicklungsumgebung vorbehalten sein sollte. Der Inhalt der Vektoren wird
  nach Ende des Hauptmoduls automatisch restauriert; dazu ist es aber
  unbedingt notwendig, da sich das Programm nicht am Laufzeitsystem vorbei
  mit 'Pterm' beendet, sondern ``normal'' terminiert, also wieder in 'System'
  zurckkehrt. Bei der Programmierung der Modulterminierung ("atexit()",
  "exit()", "Exit()") habe ich versucht dies zu bercksichtigen, kann aber
  nicht fr die Funktionsfhigkeit garantieren.

  Aus dem gleichen Grund sollten auch fr Signale wie SIGINT, SIGQUIT und
  SIGTERM Handler installiert werden, die das Programm dann entweder mit
  einer der exit-Funktionen oder normal ber das Ende des Hauptmoduls
  beenden (mittels Flag oder "longjmp()"). Geschieht das nicht, wird das
  Programm beendet, ohne da das Laufzeitsystem die Mglichkeit hat die
  Vektoren zu restaurieren.
  Bei SIGKILL besteht keine Chance die Vektoren zu restaurieren, da das
  Signal nicht abgefangen werden darf/kann. Aber dieses Signal ist ohnehin
  nur als letzte Rettung gedacht.
  Wenn man unter normalem TOS ein Programm mit ^C abbricht, werden die
  Vektoren (natrlich) auch nicht restauriert.

  Zum Thema Programmterminierung unbedingt den entsprechenden Abschnitt in
  THREADS.TXT lesen!

  brigens sollte unter MiNT/MultiTOS maximal ein SPC-Programm
  gleichzeitig laufen, denn wenn zwei oder mehr SPC-Programme parallel
  gestartet werden, hngt sich jedes ohne Rcksicht auf Verluste in die
  Vektoren ein, und nur die Adressen des zuletzt gestarteten Programms
  berleben. Wenn jetzt aus irgendeinem Grund, z.B. wegen eines
  Busfehlers, die Routine in diesem Vektor aufgerufen wird, dann ist es
  immer die des letzten Programms, unabhngig davon, ob die Ursache des
  Aufrufs in einem der anderen Programme liegt! Andersrum setzt natrlich
  jedes dieser Programme, das beendet wird, die Vektoradressen des zuvor
  gestarteten Programms ein; war dies aber zufllig das erste gestartete
  Programm, landet man wieder bei den Desktop-Bomben, obwohl eigentlich
  noch andere SPC-Programme laufen.

  Das ganze gilt natrlich nicht nur fr parallele SPC-Programme, sondern
  auch fr andere parallele Programme, die sich ohne XBRA in dieselben
  Vektoren hngen.

o Wer Signalhandler programmiert, sollte beachten, da die
  Betriebssystemmodule GEMDOS, BIOS und XBIOS nicht reentrant sind
  (das Resultat wird global (zwischen)gespeichert). Da viele weitere
  Systemmodule auf diese Betriebssystemmodule zugreifen, sollten/mssen
  Aufrufe dieser Module innerhalb von Signalhandlern vermieden werden.

o Das Load-Time-Linking ist ebenso wie bei LPR am Betriebssystem vorbei
  programmiert. Deshalb gelten alle dort genannten Einschrnkungen auch
  fr SPC!

o Offenbar hat das SPC-eigene Fenstersystem SSWiS bzw. dessen Pseudo-
  Multitasking Probleme mit ``echten'' Unterprozessen. Deshalb drfen die
  Funktionen "fork()", "vfork()" und "tfork()" nicht zusammen mit SSWiS
  verwendet werden. Das betrifft allerdings auch die SPC-Module 'Terminal'
  und 'InOut', wenn die SSWiS-Variante von 'Terminal' verwendet wird!

o Da Codegenerierung und Modullayout von SPC- und LPR-Objektdateien praktisch
  identisch sind, lassen sich mit dem Programm OBMINFO.TTP aus dem LPR-
  Verzeichnis auch bersetzte Module des SPC-Systems analysieren.
  Lediglich die Modulversion wird falsch ausgegeben und Module mit
  Priorittsangabe knnen das Programm durcheinanderbringen.

o Folgende Originalmodule des SPC-Systems werden in den Bibliotheksmodulen
  verwendet:
  - 'Storage' im Modul 'pSTORAGE', wenn Makro __USE_MEM__ nicht definiert ist.
  - 'System' im Modul 'DosSystem'.
  - 'InOut' im Modul 'StdInOut'.

  Und zustzlich in den Testmodulen:
  - 'InOut' in 'pOUT', 'T[L]MathUtil', 'TConvUtil' und den ISO-Testmodulen.


TDI, Version 3.01a (TDIM2):
---------------------------
o Verzeichnisse:
  TDIM2\
    BATCH\
    PATCHES\
    RS_PD\

o Um das Verzeichnis mit den M2LIB-Objektdateien (normalerweise das
  Verzeichnis M2LIB) dem System als Suchpfad bekannt zu machen, mu der
  vollstndige Pfad in der ASCII-Datei M2PATHS.TXT eingetragen werden. Der
  Pfad mu vor der letzten Zeile stehen; am besten in der ersten Zeile, damit
  es nicht zu Konflikten mit evtl. bereits vorhandenen gleichnamigen Dateien
  in anderen Verzeichnissen kommt (z.B. Systemdatei TextIO!).
  Das Eintragen erfolgt am besten aus dem M2OPTION.ACC: [Modula-2 Options]
  heraus mit anschlieendem Sichern der Optionen.
  Da maximal sechs Pfade in M2PATHS.TXT erlaubt sind, empfiehlt es sich
  nicht, die M2LIB-Dateien auf mehrere Verzeichnisse zu verteilen.

  Sollen die Module (neu) bersetzt werden, mu ebenfalls ein Suchpfad fr
  die Quelltexte in M2PATHS.TXT eingetragen werden. Es ist empfehlenswert,
  fr das bersetzen ein gesondertes (temporres) Verzeichnis zu whlen und
  nach dem bersetzen die Objektdateien in das dafr vorgesehene, permanente
  Verzeichnis zu kopieren. Gnstig ist z.B. ein Verzeichnis auf einer
  RAM-Disk, damit das Einlesen der Dateien schnell vonstatten geht und die
  Festplatte nicht im Dauerstre ist. Der Compiler sollte ebenfalls in
  dieses Verzeichnis kopiert und dann direkt gestartet werden, nicht ber
  M2DESK.

o In der TDI-Systembibliothek gibt es ein Modul 'TextIO', das den gleichen
  (Datei)Namen wie ein ISO-Modul hat. Wie oben bereits gesagt, mu deswegen
  der Suchpfad mit den M2LIB-Dateien vor dem Suchpfad mit den TDI-Dateien
  stehen, da sonst das falsche Modul gefunden wird. Auerdem drfen keine
  (TDI-)Module verwendet werden, die das TDI-TextIO importieren.

o BATCH\:
  Enthlt die Batchdateien MKPOSIX.BAT, MKISO.BAT, MKMISC.BAT fr die
  Bibliotheksmodule und MKXTEST.BAT, MKITEST.BAT, MKMTEST.BAT fr die
  zugehrigen Testmodule, mit deren Hilfe der Compiler alle prprozessierten
  Module in einem Rutsch bersetzt.
  Die Bibliotheksmodule mssen in folgender Reihenfolge bersetzt werden:

    MKPOSIX.BAT
    MKISO.BAT
    MKMISC.BAT

  Die Testmodule knnen natrlich erst bersetzt werden, wenn die zu
  testenden Bibliotheksmodule bersetzt sind.

  Eine Batchdatei wird dem Compiler genauso wie eine normale Moduldatei
  zum bersetzen angeboten, nur da dann alle Module, deren Name in der
  Batchdatei enthalten ist, bersetzt werden. Leider lt sich der Vorgang
  nicht abbrechen. Fehler beim bersetzen werden leicht bersehen, so da
  man nach dem Ende des bersetzungsvorgangs nach Fehlermeldungsdateien
  suchen sollte (*.ERD bzw. *.ERM); es gibt auch Fehler, bei denen trotzdem
  Objektdateien erzeugt werden, die dann allerdings fehlerhaft sind!
  Die Batchdateien mssen sich im selben Verzeichnis wie die zu
  bersetzenden Module befinden.

o MOD_TERM\:

o PATCHES\:
  Die Vergleichsroutine des Laufzeitsystems fr LONGREAL-Zahlen ist
  fehlerhaft. Es ist ein Patch fr 'GEMX' angegeben, der aber per Hand mit
  einem Dateimonitor vorgenommen werden mu. Ohne diesen Patch funktionieren
  die ISO-Module, die sich mit (LONG)REAL beschftigen, nicht korrekt.
  Der Fehler betrifft auch die Arbeit mit REAL, weil die Konvertierung
  zwischen interner und externer Darstellung (Stringreprsentation)
  grundstzlich mit LONGREAL vorgenommen wird.
  Wichtig: Dieser Patch bezieht sich auf ein unmodifiziertes 'GEMX' der
  Compilerversion 3.01a. Da in TDI-Objekdateien Prfsummen stehen, kann der
  Patch nicht verwendet werden, wenn an GEMX bereits etwas verndert wurde.
  Wer den Quelltext zu GEMX besitzt, kann den Patch natrlich auch gleich
  direkt einbauen.

o RS_PD\
  Die in diesem Verzeichnis enthaltenen Dateien wurden von Rolf Schrader
  entwickelt und zur Verfgung gestellt.

  Fr die Funktionen "DosSystem.[at]exit()" ist es ntig, das
  TDI-Laufzeitsystem um eine Modulterminierung zu erweitern.
  Die Dateien CLEANUP.SYM und CLEANUP.LNK werden am besten in eins der
  TDI-Verzeichnisse kopiert, z.B. GEMLIB.

  Weiterhin gibt es einen umfangreichen Bug-Report und einige Patches
  fr das TDI-System. Die darin beschriebenen Fehler beeintrchtigen jedoch
  (hoffentlich) nicht die Lauffhigkeit von M2LIB mit TDI.

o Das Original-TDI-Laufzeitsystem 'GEMX' hngt sich genauso wie das
  SPC-Laufzeitsystem ohne XBRA in diverse Systemvektoren ein. Deshalb
  gelten alle dort genannten Einschrnkungen auch fr TDI! Auerdem
  beachten die Exceptionhandler (Adrefehler, Busfehler usw.) nicht
  die Systemvariable _longframe, so da sie bei einer CPU 680x0 nicht
  funktionieren.

o Die ber __RANGE_CODE__, __STACK_CODE__ und  __DEBUG_CODE__ in PORTAB.M2H
  erreichbaren Laufzeitberprfungen sollten ausgeschaltet werden/bleiben, da
  der Compiler z.T. falschen Debug-Code erzeugt, der Bereichsberschreitungen
  meldet wo gar keine vorhanden sind; dies ist z.B. bei den Programmen
  'ListDir' und 'tlib' der Fall. Eine Beschreibung dieses Fehlers ist in
  RS_PD\M2_TESTS\VOP_TEST.MOD enthalten.

o Ein Programm kann keine Werte an die Umgebung zurckliefern. Vielmehr
  scheint der Rckgabewert zufllig zu sein, jedenfalls bei optimierend
  gelinkten Programmen. Eine mgliche Beschreibung und Behebung des
  Fehlers ist in RS_PD\PATCHES\TERMPATX.TXT enthalten. Das funktioniert
  zumindest bei Benutzung einer der *exit-Funktionen aus 'DosSystem'.

o Die Arbeit mit LONGREAL-Zahlen ist uerst umstndlich, da das System
  keine LONGREAL-Konstanten beherrscht, obwohl die Operationen mit LONGREAL
  im Laufzeitsystem vorhanden sind. Innerhalb der ISO-Module ist das so
  gelst, da keine Konstanten, sondern Variablen verwendet werden, die
  im Modulrumpf ber den Umweg zweier LONGCARD-Konstanten und einem
  varianten RECORD initialisiert werden.

o Falls ein ACC programmiert werden soll, mu die Abfrage auf ein ACC
  (IF NOT Accessory()) in 'args', die mit dem Makro '__USE_AES_FOR_ARGV0__'
  beim Prprozessieren aktiviert werden kann, ausgeschaltet/auskommentiert
  werden (der komplette Block innerhalb des IFs), da es mit dem Original-GEMX
  keine Mglichkeit gibt, abzufragen, ob ein Programm als Applikation oder
  ACC gestartet wurde, und deswegen Accessory() immer FALSE liefert.

  Eine andere und bessere Methode ist es, gleich in der Prozedur
  "Accessory()" den Wert TRUE zu liefern, dann erhalten auch gleich alle
  anderen Programmteile, die diesen Aufruf verwenden, den richtigen Wert.

o Entweder der Linker oder der Compiler produzieren irgendeinen Fehler,
  wenn der Rumpf eines Moduls eine bestimmte Gre berschreitet. Es
  wird zwar kein Fehler gemeldet, aber das fertige Programm produziert
  merkwrdige Abstrze.

o Folgende (Original)Module des TDI-Systems werden in den Bibliotheksmodulen
  verwendet:
  - 'Storage' im Modul 'pSTORAGE', wenn Makro __USE_MEM__ nicht definiert ist.
  - 'CleanUp' (siehe oben) im Modul 'DosSystem'.
  - 'GEMX' im Modul 'DosSystem', falls die Basepage nicht ber _sysbase
    erfragt werden soll. Defaultmig wird GEMX nicht verwendet.
  - 'InOut' im Modul 'StdInOut'.

  Und zustzlich in den Testmodulen:
  - 'InOut', 'LongInOut' und 'RealInOut' im Modul 'pOUT'.
  - 'InOut' in 'T[L]MathUtil', 'TConvUtil' und den ISO-Testmodulen.


Megamax, Version 4.3e (MM2):
----------------------------
o Verzeichnisse:
  MM2\
    BATCH\

o Um das Verzeichnis mit den M2LIB-Objektdateien (normalerweise das
  Verzeichnis M2LIB) dem System als Suchpfad bekannt zu machen, mu der
  Pfad in der Batchdatei stehen, die automatisch beim Shell-Start ausgefhrt
  wird; dies ist normalerweise die Datei MM2SHELL.M2B. In dieser Datei stehen
  mehrere Suchpfade. Das M2LIB-Verzeichnis mu unter 'DefaultPath', 'DefPath'
  und 'ImpPath' mit der im Handbuch angegebenen Syntax eingetragen werden;
  wichtig ist jeweils das fhrende Leerzeichen vor dem Pfad!

  Sollen die Module (neu) bersetzt werden, mu ebenfalls ein Suchpfad fr
  die Quelltexte definiert werden. Dies kann durch Eintragen des Pfades
  in der Batchdatei unter 'SourcePath' geschehen. Gnstiger ist es jedoch,
  in der Shell bei den Compilerparametern unter 'Ausgabepfad' ein temporres
  Verzeichnis anzugeben, in dem dann auch die Objektdateien landen und zum
  Schlu in das endgltige Verzeichnis kopiert werden knnen. Das temporre
  Verzeichnis liegt am besten auf einer RAM-Disk, damit das Einlesen der
  Dateien schnell vonstatten geht und die Festplatte nicht im Dauerstre
  ist.

  Diese Vorgehensweise gilt fr ein System in Standardkonfiguration und ist
  nur eine von vielen; fr weitere Mglichkeiten, wie z.B. das bersetzen mit
  Batchdateien oder das ndern der vom System benutzten Extensionen usw.,
  ist das Handbuch zu Rate zu ziehen.

o BATCH\:
  Um alle Module auf einmal zu bersetzen, knnen dem Make-Generator
  (ModRef, normalerweise F3) die Dateien MKPOSIX.M, MKISO.M und MKMISC.M
  als Hauptmodule bergeben werden, die alle Module der jeweiligen Bibliothek
  importieren. Zuerst mssen allerdings die POSIX-Module bersetzt werden,
  da die anderen Bibliotheken z.T. auf die POSIX-Module zurckgreifen.
  Diese Hauptmodule sollen nur dafr sorgen, da die importierten Module
  bersetzt werden, sie brauchen also nicht gelinkt oder ausgefhrt zu
  werden!
  Fr die Testmodule gibt es keine solche Mglichkeit.

o Das Systemmodul MOSCtrl installiert sich in der System- (TOS) bzw. Proze-
  (MiNT)Variable 'etv_term', um die systemeigene Modulterminierung zu
  realisieren. Wird das Modul [TOS]Debug importiert oder eins der Module
  GEMError oder SimpleError dazugelinkt (und auch noch andere Module), so
  installieren sich diese in weiteren Betriebssystemvektoren (mit XBRA) wie
  z.B. die fr Addresserror und Buserror. Der Inhalt dieser Vektoren wird
  nach Ende des Programms durch die in 'etv_term' hngende Modulterminierung
  automatisch restauriert, wobei auch die Modulterminierung selbst entfernt
  wird. Weil dies in 'etv_term' durchgefhrt wird, ist eine korrekte Funktion
  auch gewhrleistet, wenn das Programm durch ein Signal beendet wird, fr
  das kein Handler installiert war, oder mit ^C unter normalem TOS; hierbei
  wird nmlich, wie auch bei einem normalen 'Pterm', die in diesem Vektor
  installierte Routine ausgefhrt. Bei SIGKILL besteht keine Chance die
  Vektoren zu restaurieren, da das Signal nicht abgefangen werden darf/kann
  und deswegen bei der Programmbeendigung auch nicht ber 'etv_term' gegangen
  wird. Allerdings ist dieses Signal ohnehin nur als letzte Rettung gedacht.

  Diese Hartnckigkeit bei der Durchfhrung der Systemdeinitialisierung
  hat allerdings auch Nachteile: manchmal soll sie nmlich gar nicht
  ausgefhrt werden, z.B. wenn sich ein (echter) Unterproze beendet. Der
  Schlssel zur Kontrolle ber die Ausfhrung der Deinitialisierung sind die
  Variablen 'MOSCtrl.ActMOSProcess' und 'MOSCtrl.BaseProcess', die die
  Basepageadresse bei Programmstart enthalten. Ein Unterschied zwischen den
  beiden Variablen besteht nur beim Load-Time-Linking in der Shell. Die
  Deinitialisierung wird durchgefhrt, wenn einer der Werte gleich der
  Basepageadresse des aktuellen Prozesses ist. Nun haben aber z.B. mit
  'Pfork' oder 'Pvfork' erzeugte Unterprozesse dieselbe Basepage wie der
  erzeugende Proze. Der Trick ist, die beiden Variablen zum richtigen
  Zeitpunkt mit den richtigen Werten zu versorgen. Diese Vernderung stellt
  einen Eingriff in das Laufzeitsystem von Megamax dar, so da ich fr die
  Funktionsfhigkeit nicht garantieren kann.
  MOSCtrl ist im Laufe der Zeit auch ein paar mal gendert worden, vielleicht
  hat sich dabei auch die Art der Deinitialisierung gendert. Mit den
  MOSCtrl-Versionen, die ab Compiler-Version 4.3b dabei sind, scheint es
  jedenfalls zu funktionieren.

  Zum Thema Programmterminierung unbedingt den entsprechenden Abschnitt in
  THREADS.TXT lesen!

  Es ist auch zu beachten, da 'MOSCtrl.ActMOSProcess' und
  'MOSCtrl.BaseProcess' sowie darauf zugreifende Funktionen wie
  "PrgCtrl.GetBasePageAddr()" und "PrgCtrl.BaseProcess()" nur dann
  gltige Werte liefern, wenn fr den aufrufenden Proze: IsMain() = TRUE
  gilt.

o Vor allem wegen der oben genannten Schwierigkeiten der Programmterminierung
  und ihrer Lsung, kann es sehr gut sein, da die Megamax-eigenen Routinen
  fr die Prozeverwaltung und das Load-Time-Linking aus Programmen heraus
  nicht zusammen mit den Prozeaufrufen von M2LIB funktionieren; ich habe es
  allerdings auch nicht getestet. Trotzdem sollten die beiden Varianten
  nicht gemischt auftreten, besonders nicht, wenn einer der "*fork()"-Aufrufe
  aus M2LIB verwendet wird!

o Die ber __RANGE_CODE__, __STACK_CODE__ und  __DEBUG_CODE__ in PORTAB.M2H
  erreichbaren Laufzeitberprfungen sollten ausgeschaltet werden/bleiben, da
  der Compiler z.T. falschen Debug-Code erzeugt.

o Wird ein Programm durch ^C oder ein Signal abgebrochen, so ist der
  Rckgabewert an die Umgebung oftmals nicht korrekt, was bei 'Spawn'
  und 'ForkExec' beobachtet werden kann, wenn 'showcmd' abgebrochen wird.

o Die mathematischen ISO-Module untersttzen lediglich das Megamax-eigene
  Softwareformat fr REAL- und LONGREAL-Zahlen, nicht jedoch das bei
  Vorhandensein einer FPU optional verwendete IEEE-Format.

o In letzter Zeit wurde der Compiler wieder weiterentwickelt, deshalb kann
  es sein, da unterschiedliche Compilerversionen auch unterschiedliche
  Features aus PORTAB.M2H untersttzen. Insbesondere ist auf folgende
  Makros zu achten, die bei Bedarf durch Einfgen oder Entfernen
  von: ``(defined MM2)'' ein- oder auszuschalten sind:

    - IOS_proc_const

  Die in Version 4.3e eigtl. vorhandenen Prozedurkonstanten funktionieren
  allerdings nicht richtig!

o Wenn die Version 4.3c verwendet wird, mu in PORTAB.M2H das Makro MM2_43c
  durch ndern der 0 in eine 1 aktiviert werden, da sonst durch einen
  Compilerfehler bei den Value-Constructors einige Module nicht bersetzt
  werden knnen.

o Folgende Originalmodule des Megamax-Systems werden in den Bibliotheksmodulen
  verwendet:
  - 'Storage' im Modul 'pSTORAGE', wenn Makro __USE_MEM__ nicht definiert ist.
  - 'PrgCtrl' im Modul 'DosSystem'.
  - 'MOSGlobals' im Modul 'DosSystem'.
  - 'MOSCtrl' in den Modulen 'DosSystem' und 'proc'.
  - 'InOut' im Modul 'StdInOut'.

  Und zustzlich in den Testmodulen:
  - 'InOut' in 'pOUT', 'T[L]MathUtil', 'TConvUtil' und den ISO-Testmodulen.


Hnisch, Version 5.20, '94 (HM2):
---------------------------------
o Verzeichnisse:
  HM2\
    BATCH\

o Um die M2LIB-Objektdateien dem Compiler bekannt zu machen, mssen sie in
  das integrierte Make bernommen werden. Das geschieht durch den Befehl
  Einstellungen/Pfad im ACC, der normalerweise auch ber die Taste P
  erreichbar ist. In der anschlieend erscheinenden Dateiauswahlbox
  wechselt man in das Verzeichnis mit den Objektdateien (normalerweise das
  Verzeichnis M2LIB) und verlt die Box mit OK ohne vorher eine bestimmte
  Datei auszuwhlen. Dadurch werden alle Dateien bernommen, die eine dem
  System bekannte Extension haben. Befinden sich Dateien in dem Verzeichnis,
  die nicht aufgenommen werden sollen, kann als auszuwhlende Datei auch ein
  Muster angegeben werden, wie z.B. *.B. Sollen nur bestimmte Dateien
  aufgenommen werden, z.B. weil die Objektdateien bereits in einem Archiv
  zusammengefat sind, knnen diese Dateien auch einzeln ausgewhlt werden.

  Sind die Dateien auf mehrere Verzeichnisse aufgeteilt, wird der Vorgang
  entsprechend fr alle diese Verzeichnisse wiederholt.

  Sollen die Module (neu) bersetzt werden, mssen die Quelltexte ebenfalls
  in das Make bernommen werden. Das Vorgehen ist das gleiche wie bei den
  Objektdateien. Es ist empfehlenswert, fr das bersetzen ein gesondertes
  (temporres) Verzeichnis zu whlen und nach dem bersetzen die
  Objektdateien in das dafr vorgesehene Verzeichnis zu kopieren. Gnstig ist
  z.B. ein Verzeichnis auf einer RAM-Disk, damit das Einlesen der Dateien
  schnell vonstatten geht und die Festplatte nicht im Dauerstre ist.

  Diese Vorgehensweise gilt fr ein System in Standardkonfiguration und ist
  nur eine von vielen; fr weitere Mglichkeiten, wie z.B. das bersetzen mit
  einer Kommandozeile, das ndern der vom System benutzten Extensionen oder
  das Erstellen von Archiven usw., ist das Handbuch zu Rate zu ziehen.

o BATCH\:
  Um alle Module auf einmal zu bersetzen, knnen dem integrierten Make
  die Dateien MKPOSIX.M, MKISO.M und MKMISC.M als Hauptmodule bergeben
  werden, die alle Module der jeweiligen Bibliothek importieren. Zuerst
  mssen allerdings die POSIX-Module bersetzt werden, da die anderen
  Bibliotheken z.T. auf die POSIX-Module zurckgreifen.
  Diese Hauptmodule sollen nur dafr sorgen, da die importierten Module
  bersetzt werden, sie brauchen also nicht gelinkt zu werden!
  Fr die Testmodule gibt es keine solche Mglichkeit.

  Da die Anzahl der Dateien recht hoch ist, kann es sein, da der Speicher
  fr Compiler und Programm (im Optionen-Dialog) erhht werden mu.
  Bei mir betragen beide Werte 300kB, was auch fr die zustzliche Benutzung
  von ``crystal'' noch reicht.

  Auerdem sollten die Objektdateien der bersichtlichkeit wegen zu Archiven
  zusammengefat werden (mit LIB.TTP).

o Je nach Compilerversion sind bereits die Bezeichner BYTESET und LONGSET
  vordefiniert, so da es bei der bersetzung von PORTAB, auch wieder je
  nach Version, zu Warnungen oder Fehlermeldungen kommen kann. Wenn
  Fehlermeldungen auftreten, mssen die Bezeichner in der HM-Programmdatei
  mit einem Dateimonitor durch gleichlange anderslautende Bezeichner
  ersetzt werden (z.B. ByteSet und LongSet). Frher waren BYTESET
  und LONGSET in PORTAB einfach auskommentiert, da sie in M2LIB nicht
  verwendet werden; damit war dieses PORTAB allerdings nicht mehr
  kompatibel zum Original-PORTAB aus 'crystal' (Wer 'crystal' nicht
  verwendet, kann ja die Bezeichner in PORTAB auch wieder auskommentieren,
  anstatt den Compiler zu patchen).

o Wer Signalhandler programmiert, sollte beachten, da die
  Betriebssystemmodule GEMDOS, BIOS und XBIOS nicht reentrant sind
  (Rcksprungadresse und Register werden global gesichert). Da viele weitere
  Systemmodule auf diese Betriebssystemmodule zugreifen -- insbesondere
  'Terminal' und 'InOut' --, sollten/mssen Aufrufe dieser Module innerhalb
  von Signalhandlern vermieden werden.

o Es gibt Compileroptionen, die nicht im Quelltext, sondern nur im Accessory
  (oder der Programmdatei, je nachdem) in der Optionen-Dialogbox gesetzt
  werden knnen. Die Einstellung einiger dieser Optionen ist auch fr die
  Module aus M2LIB von Bedeutung; es handelt sich hierbei um die Festlegung
  der Speichergren von CARDINAL, INTEGER und REAL ($i, $w und $r). Die
  Einstellung dieser Optionen mu mit den Makros __LONG_WHOLE__ und
  __LONG_REAL__ in PORTAB.M2H bereinstimmen. Defaultmig ist bei den
  entsprechenden M2LIB-Modulen der Typ REAL mit SHORTREAL identisch und die
  Typen CARDINAL und INTEGER mit LONGCARD und LONGINT, so da gegebenenfalls
  per Hand die Option $r aktiviert und die Optionen $i und $w deaktiviert
  werden mssen. Diese Optionen knnen im Quelltext zwar nicht gesetzt aber
  immerhin abgefragt werden; deshalb gibt es am Anfang jedes Moduls eine
  kleine berprfung, die fr Syntaxfehler beim bersetzen sorgt, falls
  Makros und Optionen nicht bereinstimmen. Wenn das bersetzen nicht
  funktioniert, sollte also erstmal die Einstellung dieser Optionen geprft
  werden.

o Der Compiler wurde stndig weiterentwickelt, deshalb kann es sein, da
  unterschiedliche Compilerversionen auch unterschiedliche Features aus
  PORTAB.M2H untersttzen. Insbesondere ist auf folgende Makros zu achten,
  die bei Bedarf durch Einfgen oder Entfernen von: ``(defined HM2)''
  ein- oder auszuschalten sind:

    - ISO_value_constructor
    - ISO_opaque_far_imp
    - ISO_recursive_proc_decl
    - ISO_packedset
    - ISO_loc
    - ISO_val
    - ISO_ptr_arith

  Bei einer Compilerversion mit einem Datum von '94 oder aktueller
  sind alle diese ISO-Features vorhanden.

o Folgende Originalmodule des Hnisch-Systems werden in den Bibliotheksmodulen
  verwendet:
  - 'Storage' im Modul 'pSTORAGE', wenn Makro __USE_MEM__ nicht definiert ist.
  - 'System' im Modul 'DosSystem'.
  - 'TOS' im Modul 'DosSystem', falls die Basepage nicht ber _sysbase
    erfragt werden soll. Defaultmig wird TOS verwendet.
  - 'InOut' im Modul 'StdInOut'.

  Und zustzlich in den Testmodulen:
  - 'BufInOut' und 'BufRealInOut' im Modul 'pOUT'.
  - 'InOut' in 'T[L]MathUtil', 'TConvUtil' und den ISO-Testmodulen.


Anpassung an andere Compiler
============================

Wer M2LIB an ein anderes System anpassen will, mu mindestens die folgenden
Dinge beachten:

o In der Header-Datei PORTAB.M2H mssen die Makros entsprechend den
  Eigenschaften des Compilers definiert bzw. nicht definiert werden.

o Die Module PORTAB und pSTORAGE mssen an den Compiler bzw. an das
  mitgelieferte Storage-Modul angepat werden.

o In der Header-Datei OSCALLS.M2H mssen die (Hilfs)Makros fr die
  Betriebssystemaufrufe im ersten Teil der Datei den Aufrufkonventionen
  des Compilers angepat werden.

o Bei Assemblerprozeduren mssen Prozedurprolog und -epilog angepat werden;
  das betrifft:

  - das gesamte Modul 'blk'.
  - das gesamte Modul 'jump'.
  - die Prozeduren "vfork()" und "startup()" im Modul 'proc'.
  - die Prozeduren "signal()" und "sigaction()" im Modul 'sig'.
  - die Prozedur "ExecuteSuper()" im Modul 'DosSystem'.
  - die Prozedur "r2s()" im Modul 'FConvBase'.
  - die gesamten Module 'LowReal' und 'LowLong'. Bei diesen Modulen kommt
    noch hinzu, da evtl. alle Prozeduren vllig neu zu schreiben sind,
    wenn nicht das IEEE-Format verwendet wird.
  - die Module 'RealMath', 'RealXMath', 'RealSupport', 'LongMath',
    'LongXMath', 'LongSupport': Bei vielen Prozeduren sind
    Berechnungsalternativen fr eine FPU vorhanden, die in Assembler
    geschrieben wurden.

o Im Modul 'DosSystem' mu die systemspezifische Modulterminierung
  implementiert werden.

o Im Modul 'DosSystem' mu die Adresse der Basepage ermittelt werden, falls
  dies nicht ber die Systemvariable _sysbase geschehen soll.

o In den 'LC*'-Modulen mu (eine mglichst platz- und zeitsparende) Methode
  gefunden werden, eine groe Anzahl von Strings und deren Adressen
  abzuspeichern.


Es kann auch sein, da im Quellcode spezielle Abfragen auf das System
ntig werden, z.B in der Form:

        ...
        #if (defined <System>M2)
                ...
        #else
                ...
        #endif
        ...

Es sollte jedoch versucht werden, smtliche Compiler-Abhngigkeiten in
die Header-Dateien zu verlegen -- soweit mglich.

Am besten ist es, mal die Testmodule (mit der Endung .MPP) zu
bersetzen, und sowohl unter GEMDOS als auch unter MiNT laufen zu
lassen. Falls der Compiler fr INTEGER und CARDINAL per Option 16 oder
32 Bit benutzen kann, sollten auch beide Einstellungen ausprobiert werden.

Die ``Test''-Module sind allerdings keine vollstndigen Tests,
vielmehr werden einfach nur einige der Funktionen mit
unterschiedlichen Parametern aufgerufen, und geprft, ob das Erwartete
passiert. Z.T. ist auch die berprfung durch den Benutzer
erforderlich, oder es werden einfach nur Systemeinstellungen
abgefragt. Fr weitere Informationen ber die Anwendung der Testmodule
mu der Quellcode durchgesehen werden.

Da bei solchen Anpassungen einiges schief gehen kann, sollte
vielleicht eine RAM-Disk benutzt werden, auf der dann Dateien ohne
Auswirkungen zerstrt werden knnen... Auf jeden Fall bernehme ich
keine Verantwortung fr zerschossene Festplatten oder hnliches...

Eine Anpassung an *IX- oder gar DOS-Systeme bentigt sicherlich
einiges an Arbeit, ich will aber niemanden davon abhalten...

Generell: Ich wrde mich freuen, wenn mir jemand, der eine Anpassung
vorgenommen hat, eine Kopie zukommen lt. Das gilt natrlich auch fr
Anregungen, Fehlermeldungen u..
